home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17241 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.6 KB  |  90 lines
  1. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  2. Path: new-news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: ANSI C and POSIX
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <Dpv6qy.2p3@eskimo.com>
  7. Sender: news@eskimo.com (News User Id)
  8. Organization: schmorganization
  9. References: <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <DpnxAF.6xq@eskimo.com> <dewar.829185159@schonberg>
  10. Date: Sun, 14 Apr 1996 18:16:08 GMT
  11.  
  12. In article <dewar.829185159@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
  13. > Steve said/asked
  14. >> An example was brought up which, I gather, boils down to
  15. >>        char buf[100];
  16. >>        /* exactly 68 characters are known to be available on fd */
  17. >>        read(fd, buf, 1000);
  18. >> It wasn't clear whether this was being presented as a real-world
  19. >> example of a portability problem...
  20. > 
  21. > Of course it is being brought up as an example of a portability problem.
  22. > As for
  23. >   (a) should be written
  24. >   (b) should be portable in practice
  25. >   (c) should work
  26. > I would say, historically, (b) and (c),
  27.  
  28. I would probably agree, but only if "should" were changed to
  29. "happened to".
  30.  
  31. > but not necessarily (a). If the
  32. > spec of the POSIX read were defined to say "the buffer must be at least
  33. > as long as the data that is read", then certainly (b) and (c) would be
  34. > true.
  35.  
  36. But that would be a terrible way for the Posix spec to define it.
  37.  
  38. > As for (a), note that of course *no one* would explicitly write
  39. > the dubious code, it occurs in the context of a loop, something like
  40. > 
  41. >    while (p < endbuf) {read(fd, p, 8192); p+=8192;)
  42.  
  43. Thank you!  Call me lazy, call me stupid, but I was too lazy or
  44. stupid to look beyond previous artificial example to see if there
  45. might be a real one behind it.  (I suspected there might be one,
  46. but I was too laz... oh, I'm repeating myself.)
  47.  
  48. > Of course it is possible to modify this code so that
  49. > the last read does not have an excessive count, but the resulting code
  50. > is a little more complex.
  51.  
  52. Of course.  I've written that loop countless times, but always in
  53. the slightly "more complex" way which simultaneously decrements a
  54. chars-left-to-read count as it increments the pointer.  It would
  55. honestly never have occurred to me that the code could in some
  56. cases be "simplified" to fix read's third argument at a constant.
  57. (The simplification is of course only possible if the input size
  58. is known and is known not to be growing.)
  59.  
  60. > The issue is not whether this code is defensible or not. Clearly this was
  61. > in fact a significant bug, since the code broke on Linux, and this was
  62. > intended to be portable, so it was wrong, caused trouble, and had to be
  63. > fixed. In that sense it was certainly wrong!
  64. > 
  65. > However, given the vague definition of read, it is easy to see how the
  66. > coder here in fact assumed that (b) and (c) were true...
  67.  
  68. Perhaps.  My opinion (but I'm speculating, and the thread is
  69. getting old, so I probably shouldn't) is that the original coder
  70. was probably careless.  A more careful programmer would have
  71. written the code safely regardless of what the spec for read()
  72. said; a careless programmer probably wouldn't have scrutinized
  73. the spec for read() at all.
  74.  
  75. > If the spec of read had said: "the buffer must be at least the length
  76. > given by the third parameter, even if the actual data is smaller", then
  77. > of course the error would not have been made in the first place.
  78.  
  79. Of course?  I fear you may be a bit of an optimist.
  80.  
  81. > And that, all along has been my point. Careful specification of
  82. > interfaces, and accurate knowledge of these specifications, can
  83. > definitely improve portability.
  84.  
  85. In none of the above do I intend to argue against careful
  86. specification of interfaces.
  87.  
  88.                     Steve Summit
  89.                     scs@eskimo.com
  90.